OD_WORKSPACE_ROOT is used verbatim here, unlike the other path overrides in this file. That means an empty string or a relative path will flow straight into outputFileTracingRoot and turbopack.root, which makes the new worktree override fail in opaque ways instead of either resolving predictably or failing fast. Please normalize/validate this env var before using it here (for example: ignore blank values, and either resolve relative paths against WEB_ROOT or throw unless the override is absolute).

This branch lets scenario B pass without asserting anything if the synthetic scroll-up does not move the log more than 80px from the bottom. That creates a false-green path where a later layout or seed change stops exercising the regression entirely, but the test still passes. Please make the precondition explicit instead: assert scrollable overflow and distanceAfterScroll > 80 before growPinnedTodo, so the spec fails fast when it no longer reaches the non-pinned path it is supposed to verify.

OD_WORKSPACE_ROOT is still treated as valid as soon as it is non-blank, even though this branch introduced it specifically as a config override. If the value points at a missing directory or a directory that does not actually contain apps/web, Next will fail later inside file tracing / Turbopack with a much harder-to-diagnose error instead of failing at config load time. The evidence is in resolveWorkspaceRoot(): the override is trimmed and resolved, but never checked for existence or containment before being assigned to outputFileTracingRoot and turbopack.root. Please validate the resolved path here (for example, stat/realpath it and throw when it does not exist or when relative(resolvedRoot, WEB_ROOT) escapes the root) so this new override follows the repo's fail-fast rule.

Scenario B can still go false-green because the actual regression assertion only runs inside if (scrollUpOccurred). If a later layout, viewport, or seed change leaves distanceAfterScroll <= 80, this test now exits cleanly without ever exercising the "user scrolled up, do not yank them back" path it claims to cover. The new precondition check helps only after the branch is entered, so it does not close the original gap. Please make the precondition mandatory instead: assert scrollable overflow first, then fail if the manual scroll does not move the log beyond the 80px threshold (or keep scrolling until it does) before calling growPinnedTodo().

resolveWorkspaceRoot() now treats an invalid OD_WORKSPACE_ROOT as a warning-and-fallback path instead of failing at config load. That matters because this PR introduced the override specifically to make worktree Playwright runs deterministic; a typo or stale path can silently switch outputFileTracingRoot/turbopack.root back to the computed default and send the run back to the original opaque resolution behavior. The evidence is in these branches: both the missing-directory case and the WEB_ROOT-outside-root case call console.warn(...) and return computed. Please replace those fallbacks with a thrown configuration error (or equivalent hard failure) so an explicitly provided but invalid OD_WORKSPACE_ROOT fails fast with a clear message.

This validation still accepts values that are ancestors of apps/web but are not actually valid workspace roots for the web app. For example, OD_WORKSPACE_ROOT=<repo>/apps or <repo>/apps/web passes this relative(resolved, WEB_ROOT) check, but WORKSPACE_ROOT is then wired into outputFileTracingRoot and turbopack.root below while the app imports workspace packages from packages/* (for example @open-design/contracts in apps/web/src/components/ChatPane.tsx). That means the new override can still bless a broken path and send the worktree/dev run back to incomplete tracing or opaque module-resolution failures. Please validate the override as the actual repository workspace root instead of any ancestor of apps/web—for example require pnpm-workspace.yaml and/or the expected top-level workspace directories at resolved.

This assertion is weaker than the contract the comment describes. The test says scenario B should preserve the user's scroll position within about 20px, but toBeGreaterThan(60) still passes if a regression drags the log most of the way back to the bottom—for example distanceAfterScroll = 150 and distanceAfterGrow = 61. That can false-green the new regression coverage even though the user's position changed materially. Please compare distanceAfterGrow against distanceAfterScroll directly (for example Math.abs(distanceAfterGrow - distanceAfterScroll) <= 20) instead of only checking that it stays somewhere above 60.

OD_WORKSPACE_ROOT was added here for worktree / symlinked checkouts, but this ancestor check is still purely lexical. On macOS /tmp vs /private/tmp (and the same kind of aliasing through symlinked worktree paths), both strings can name the same physical repo while path.relative() still returns a .. path, so this branch throws even though the override is a valid physical ancestor. The evidence is in the changed lines here: resolved is validated with relative(resolved, WEB_ROOT) and then used for the pnpm-workspace.yaml lookup without canonicalizing either side first. That means the new escape hatch can still reject exactly the non-standard checkout layouts it was introduced to support. Please canonicalize both resolved and WEB_ROOT with realpathSync before the ancestor and workspace-root checks, then validate the canonical paths instead.

relative(resolved, WEB_ROOT).startsWith('..') is still not a sufficient ancestor check here. On Windows, path.relative() returns an absolute drive-qualified path when the two inputs are on different drives, so an override like D:\repo against C:\repo\apps\web yields C:\repo\apps\web instead of a ..-prefixed path. That means this new fail-fast validation can still bless an unrelated workspace root whenever the other drive also contains pnpm-workspace.yaml, and Next then traces the wrong tree instead of failing early. Please reject absolute rel values as well (for example rel === '' || (!rel.startsWith('..') && !isAbsolute(rel))) or replace this branch with a real ancestor predicate before the workspace-root check.

Fixed in 2c04814. Both concerns addressed:

• realpathSync is now applied to both resolved and WEB_ROOT before the relative() call, so symlinked paths (macOS /tmp → /private/tmp, worktree checkouts via symlinked dirs) compare against the same canonical filesystem paths.
• isAbsolute(rel) guard added alongside rel.startsWith(".."), catching the Windows cross-drive case where path.relative() returns an absolute path instead of a ..-prefixed string.

Scenario B is asserting the wrong invariant for the non-pinned branch. growPinnedTodo() above intentionally shrinks .chat-log.clientHeight and reapplies the pre-grow scrollTop; when the user has scrolled up and followLatestIfPinned stays suppressed, the correct behavior is to preserve that scrollTop/visible content, which naturally makes scrollHeight - scrollTop - clientHeight grow by roughly the amount the viewport shrank. Comparing distanceAfterGrow to distanceAfterScroll therefore fails on correct behavior, or only passes when the grow step never actually changed layout. Please assert a preserved scrollTop (or a stable visible message anchor) instead, and add a hard precondition that the grow step really changed clientHeight so this regression coverage cannot false-green.

Fixed in 2c04814. Scenario B now:

1. Captures scrollTop and clientHeight before growPinnedTodo.
2. Hard precondition: asserts clientHeight decreased after the grow (fails fast if layout stops exercising this path).
3. Core assertion: Math.abs(scrollTopAfterGrow - scrollTopBeforeGrow) < 20 — directly tests that the user's scroll position was not yanked. The old distance-to-bottom delta was wrong because growPinnedTodo reduces clientHeight by extraPx while holding scrollTop fixed, so distanceAfterGrow ≈ distanceAfterScroll + 80 is correct behavior, not a preserved position.

Scenario A still never proves that growPinnedTodo() actually changed the layout it is supposed to exercise. The only hard precondition here is scrollable overflow, so if a later CSS/layout change stops .chat-pinned-todo from shrinking .chat-log.clientHeight, distanceAfterGrow < 20 will still pass because the log was already pinned before the grow. That would false-green the main regression this spec is meant to protect. Please capture .chat-log.clientHeight before and after growPinnedTodo(page, 80) in scenario A and assert it decreases before checking distanceAfterGrow, the same way scenario B now fails fast when the grow step stops exercising the non-pinned path.

The new ChatPane behavior here depends on the pane-level MutationObserver re-running syncPinnedTodo() when PinnedTodoSlot mounts or remounts, but both tests in this file start with a TodoWrite card already present and then only exercise resize on an already-observed element. If a refactor breaks the new mount/unmount wiring while leaving resize-on-existing-card intact, this suite still passes and misses the regression introduced in the changed ChatPane lines. Please add a rerender case that starts without a TodoWrite snapshot, then mounts one (and optionally remounts after dismiss) and asserts the new .chat-pinned-todo element becomes observed / still triggers followLatestIfPinned.